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(57) Abstract: A system and method for automatically dispatching delivery services (140) which provides greater convenience to 
customers and optimizes the delivery services' business objectives. According to one embodiment, the invention enables customers 
to recognize effident a^livery of prepared meals^while effecunting inaeasedjevenu^ deliv- 
ery services, ^delivery se rvice (150 ) receives a prepared meal order from i a customer j!20> and urmiediately det 
availaDiEry^^ time.' A driveris *Sa^ 

wm'ffluiiuze^^ 

tht^etfed reltaur*^ Tlux>ughout_me process, the 

central controller ( 110) monitors various parameters including, but not limited to, traffic and weather conditions, driver availability, | 
restaurant conditions, driver history, customer location, driver location and re staurant location to minimize delays and maximize 
deliveries. 
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METHOD AND S YSTEM FOR A UTOMA TIC 
DISPATCHING OF DELIVERY SERVICE 

FIELD OF THE INVENTION 

The present invention relates generally to delivery services and, more particularly, to 
a method and system for automatic dispatching of delivery service. 

BACKGROUND OF THE INVENTION 

Although methods and systems presently exist for delivering goods or merchandise, 
such delivery services are largely inefficient. For example, delivery services rarely monitor 
and calculate the effects of various parameters that may effect the optimization of the 
delivery service business. Moreover, the current methods and systems rarely utilize the 
proper resources to minimize the delivery drivers* execution driving time and associated 
transactional time. Accordingly, a delivery services often rely on larger delivery personnel 
and fail to optimize its business objectives (i.e., maximize revenue, profits, deliveries, and the 
like). 

One such example relates to delivery of prepared meals in the restaurant business. In 
addition to dining at a restaurant, a customer may acquire prepared meals from meal 
providers (i.e., restaurants and grocers) for dining in a customer's home, office, or other 
location away from the restaurant or grocer. In some instances, customers purchase and pick 
up the prepared meal at the restaurant or grocer. In other instances, customers place a 
prepared meal order for delivery. In fact, as society continues to place a heavier premium on 
"free time," placing such orders for delivery has become more ubiquitous. 

Although methods presently exist for delivering prepared meals, such methods are 
largely inefficient. For example, the most common type of meal delivery service is where a 
specific restaurant offers deliveries to customers in which delivery orders are placed by the 
customer with that restaurant or grocer. Such a system is inefficient as each restaurant must 
hire its own delivery staff to execute customer orders. Moreover, because the delivery staff 
only serves one restaurant (its employer), restaurants employing such a system often find that 
the demand for its delivery staff frequently fluctuates. Accordingly, circumstances often 
arise where the delivery personnel is either over-staffed or under-staffed. In other words, at 
times, the restaurant is failing to meet its customers' expectation of expeditious delivery, and, 
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at other times, by over-staffing in delivery personnel, the restaurant is failing to maximize its 
profit margins by over-staffing in delivery personnel. 

Restaurants and grocers also execute meal deliveries by simply employing a third 
party who service that meal provider along with several other meal providers. Because the 
third party providing the service is typically an independent contractor, the meal provider 
may be free of the cost issues associated with hiring the precise number of delivery personnel 
to satisfy its delivery demand. The problems with such services, however, are numerous. 
For example, to ensure reliability, delivery services must be sure to have an adequate number 
of employees. Besides hiring the maximum number of employees required to handle 
potential deliveries, these services have little means to ensure timely deliveries. Such a 
system results in higher costs to the delivery service and therefore higher costs to the 
participating meal providers. Moreover, because these services do not utilize adequate 
tracking systems of its customer demand and meal delivery system, efforts to minimize 
delivery time and delivery personnel are not effective. By failing to minimize delivery time, 
more delivery personnel is required, resulting in higher costs to the meal providers. 
Moreover, customers often become dissatisfied as a result of delay in deliveries. Finally, a 
longer delivery time often has a detrimental effect on the food quality realized by customers. 

SUMMARY OF THE INVENTION 

As set forth below, a need exists for an improved method and system for 
automatically dispatching delivery services for the delivery of goods or merchandise which 
provides greater convenience to customers and optimizes the delivery services' business 
objectives. The method and system of the invention satisfies the problems identified above. 

Although the delivered goods may apply to any type of merchandise (i.e., flowers, 
commodities, clothing, books, hardware, etc.), the embodiment included herein addresses 
delivery of prepared meals. According to one embodiment, the invention enables customers 
to recognize efficient delivery of prepared meals while effectuating increased revenues to 
participating restaurants and meal delivery services. 

A delivery service receives a prepared meal order from a customer and immediately 
determines driver availability and estimated delivery time. A driver is selected to pick up the f[ 
meal at the selected restaurant based on parameters that minimize delivery delays. While the 
driver is proceeding toward the selected restaurant, the meal is prepared. The driver then j 
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delivers the meal to the customer. Throughout the process, a central controller monitors 
various parameters, including but not limited to traffic and weather conditions, driver 
aTOifability.-restaurantxonditions, driver history, custom^ lo^tioiTand^ 
restau^^ delive^?.j~. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The accompanying drawings illustrate certain embodiments of the invention. 
Fig. 1 illustrates a system according to one embodiment of the present invention; 
Fig. 2 illustrates one embodiment of the central controller used in the system shown 

Fig.l; 

Fig. 3 illustrates a sample of the contents of the customer table stored in the central 
controller shown in Fig. 2; 

Fig. 4 illustrates a sample of the contents of the restaurant table stored in the central 
controller shown in Fig. 2; 

Fig. 5 illustrates a sample of the contents of the driver table stored in the central 
controller shown in Fig. 2; 

Fig. 6 illustrates a sample of the contents of the orders table stored in the central 
controller shown in Fig. 2; 

Fig. 7 is a flowchart illustrating a process of placing a restaurant delivery order 
executed by the system shown in Fig. 1. 

Fig. 8 is a flowchart illustrating a fulfillment process executed by the system shown 

Fig. 1. 

Fig. 9 is a flowchart illustrating a driver selection process executed by the system 
shown in Fig. 1 . 

Fig. 10 is a diagram illustrating a menu of the pocketnet module shown in Fig. 1 . 
DETAILED DESCRIPTION 

System Of The Invention 

As noted above, the delivered goods may apply to any type of merchandise (i.e., 
flowers, commodities, clothing, books, hardware, etc.) as well as any type of vendor 
including, but not limited to, restaurants or grocers. It should be noted, however, that the 
embodiment included herein addresses delivery of prepared meals. Fig. 1 shows an 
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embodiment of a system incorporating the present invention. In Fig. 1, the system includes a 
central controller 1 10, configured to receive information from one or more customers at 
remote customer terminals or interface user devices 120, and transmit data to at least one 
operator, customer service representative, dispatcher, restaurant and/or driver. It should be 
noted that the terms meal provider, restaurant and grocer are used interchangeably herein and 
means any restaurant, grocer, delicatessen, diner, etc. that prepares ready to eat food for 
delivery. 

Central controller 1 1 0 preferably comprises a processor-based system that maintains 
tables and information relating to delivering meals of a specified cuisine at a specified 
delivery time. Central controller 1 1 0 provides the graphical user interface (GUI) to 
customers at user interface devices 120 which allows customers to place orders with one or 
more restaurants via one or more operator user interface devices 160. In one embodiment, 
user interface devices 120, 130, 160, 170 may be a computer comprising one or more central 
processing units, one or more data storage devices, a monitor, a keyboard and/or any other 
components that may allow a user to implement the commands of the software and hardware 
functions described herein. In alternative embodiments, the user interface device 120 may be 
a telephone, facsimile, online access device, voice response unit or the like. 

Central controller 110 stores information received from customers in customer table 
352, restaurant table 354 driver table 356 and orders table 358. As described more fully 
below, this information is used to receive orders from the customer and notifies restaurant(s), 
driver(s) and dispatcher(s) of outstanding and executed orders. Also, the central controller 
110 monitors outstanding delivery orders and drivers' availability and position. The structure 
of certain embodiments of the central controller 1 10 is described below in connection with 
Fig. 2. 

Customers include individuals wishing to place a delivery order for a meal at a 
participating restaurant. Operators 160 include individuals or user interface devices that 
receive a meal delivery order. The information received by the operator(s) 160 is 
communicated to the central controller 1 10. The customer service representatives 170 are 
individuals or user interface devices that effectuate updates to customers and that receive 
information from the dispatcher and/or central controller for communication to the customer. 
Although the operators and customer service representatives are illustrated separately, these 
entities may be combined. Moreover, in another embodiment, the functions of the operators 
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and/or customer service representatives may be accomplished electronically by the central 
controller 110. 

A meal delivery order is an order for the delivery of a meal prepared by a 
participating restaurant including options such as a utensil order, store run order and gratuity. 
In one embodiment, customers register with the dispatching service, select the cuisine type, 
restaurant and menu items and place a meal delivery order sent to the central controller 1 10 
through user interface device 120. The user interface device may be the customer's computer 
or internet access device. In another embodiment, the user interface device 120 may be a 
telephone. 

Customers can transmit customer information and meal delivery order information in 
various ways. For instance, customers may provide this information electronically by means 
of the internet. This is done by completing registration and order pages electronically from 
the user interface device 120 to the central controller 1 10, which provides a customer 
interface in the form of a web page on the internet. Two alternative ways for customer to 
transmit this information to central controller 110 include (1) telephoning live operators at 
central controller 1 10, to verbally provide information which is entered into the system via 
operator terminals; and (2) telephone answering services at central controller 1 10 that provide 
programmed responses based on information received from each customer. 

Dispatchers 150 em ployed by a meal delivery ordlipat^^ 
between the customers, drivers and resta urant may b e 

parTof the central controller. Whereas^jn^ajtotheTem^ A t o 
the central controller. The meal delivery service receives all customer information, receives 
meal delivery orders, and executes open orders by interfacing with the available drivers and 
participating restaurants. In one embodiment central controller 1 1 0 transmits customer 
information and meal delivery orders to the available drivers by means of a wireless 
communication medium. Moreover, a restaurant selected by a customer is in communication 
with central control 1 10 by means of the internet. In anther embodiment, such information 
may be transmitted by facsimile, an operator utilizing a telephone, e-mail, or the like. Open 
orders may be terminated by preparing and delivering meals to the customer or by 
cancellation of the order by the customer prior to initiating meal preparation. 

Fig. 2 illustrates one embodiment of the central controller 1 1 0 for a system according 
to the present invention. As shown in Fig. 2, central controller 1 1 0 includes central 
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processing unit (CPU) 240, random access memory (RAM) 220, read-only memory (ROM) 
230. and large capacity storage device 250. CPU 240, preferably comprising a conventional 
microprocessor such as an Intel Pentium Processor, is electronically coupled to each of the 
central controller's 110 other elements. 

CPU 240 executes program code stored in one or more of RAM 220, ROM 230 and 
storage device 250 to carry out the functions and acts described in connection with central 
controller 110. CPU 240 preferably comprises at least one high-speed digital data processor 
adequate to execute program modules for executing meal delivery orders placed by 
customers. These modules are described in connection with Figs. 7-10. CPU 240 interacts 
with RAM 220, ROM 230 and storage device 250 to execute stored program code according 
to conventional data processing techniques. 

User interface devices 120, 130, 140, 160 and 170 comprise devices for allowing 
central controller 1 1 0 and dispatchers 1 50 to communicate with customers and participating 
restaurants. Communication between interface devices 120, 130, 160, 170 and the controller 
1 1 0 is preferably electronic by means of the internet and preferably includes a conventional 
high speed modem employing known communication protocols capable of decrypting 
encrypted data received from the interface user devices 120, 130, 160, 170. Communication 
between pocketnets 140 and the central controller 1 10 and dispatchers 150 is preferably by a 
wireless communication means employing known communication protocols capable of 
encrypting and decrypting information communicated between these units. 

Large capacity storage device 250 contains transaction processor 260, and at least one 
delivery database including one or more tables, for example, customer table 352, restaurant 
table 354, driver table 356 and orders table 358. Transaction processor 260 maintains, 
determines and accesses data stored in tables 352, 354, 356, 358 and prepares customer and 
order information for transmission to available drivers and subscribing restaurants as 
described in connection with Figs. 7-10. Transaction processor 260 may comprise a separate, 
conventional CPU/microprocessor, or a portion of the operating function of CPU 240. 

Customer table 352 contains data about customers that register with the meal delivery 
service. The data is used to execute delivery of a meal order, communicating the status of an 
outstanding order, as well as advertising meal promotions to customers. 

Restaurant table 354 contains information about each participating restaurants 
including cuisine type, restaurant name, food preparation type, hours of operation, menu 
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items and pricing information. Driver table 356 contains information relating to the driver's 
availability, location, driver history and reconciliation information. Orders table 358 contains 
information about each outstanding meal delivery order including desired delivery time, order 
status, meal price, and the like. Samples of the respective fields contained in tables 352. 354, 
356 and 358 are shown and described more fully below in connection with Figs. 3-6. 

Table Formats 

Samples of the contents of tables 352, 354, 356 and 358 are shown in Figs. 3-6, 
respectively. The specific data and fields illustrated in these figures represent only one 
embodiment of the records stored in the tables of the invention. It should be understood that, 
in one embodiment, all tables combined may make up one database. lii another embodiment, 
multiple databases may exist, each containing one or more table. 

In most cases, the fields shown in Figs. 3-6 are self-explanatory. It is to be 
understood that the data and fields, as well as the number of tables, can be readily modified 
from the described embodiment and adapted to provide variations for operating the system 
and method described, including executing meal delivery orders and gathering customer 
information. Furthermore, each field may contain more or less information. For example, an 
address field may be divided into separate fields containing street address, apartment number, 
city, state, zip code, telephone number and e-mail. 

Customer table 352 maintains (among other information) a compilation of all 
information provided by each customer in response to a series of prompts (fields) provided to 
the customer via user interface device 120. In one embodiment, the information is entered by 
the customer into fields of a web page. Each record in customer table 352 corresponds to 
one customer. 

Fig. 3 illustrates a sample record. As shown in Fig. 3, customer table 352 contains 
fields corresponding to, for example, customer ID, customer name, customer address and e- 
mail address, customer location coordinates, registration date, payment type, credit card 
information and personal identifier (password). The data that is retrieved directly from 
customers' answers to prompts on a web page include the customer name, customer address 
and e-mail address, personal identifier and credit card number. 

Most of the fields illustrated in Fig, 3 are self explanatory. The customer location 
coordinate may be an identifier recognized by, for example, standard global position software 
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and is useful in determining the most appropriate driver for an outstanding order based on 
restaurant, driver and customer location. Registration date is the date a customer registered 
with the meal delivery service website. 

The personal identifier provided by the customer is any information known to the 
customer but not known to the general public and is used to prevent others from logging in 
under the customer's user ID. The central controller 110 uses the personal identifier to verify 
that the customer placing a meal delivery orders is in fact the same customer who initially 
registered with the meal delivery service. From this data and data stored in other tables, the 
data for the remaining fields can be generated. 

Restaurant table 354 contains information about a participating restaurant. A 
participating restaurant is a meal provider (restaurant or grocer) that has an agreement with 
the meal delivery service for fulfilling meal delivery orders placed by customers. Fig. 4 
illustrates a sample record of restaurant table 354. As shown in Fig. 4, restaurant table 354 
contains fields corresponding to, for example, restaurant identification code, restaurant name 
and address, restaurant location coordinate data, food type, menu items, item descriptions, 
additional offerings, item prices, food preparation time and restaurant facsimile number and 
e-mail address. 

The food preparation time is the amount of time that is required to prepare the meal 
ordered by the customer. In other embodiments, particularly where that which is being 
delivered is not a prepared meal, the merchandise pick up time, preparation and/or ready time 
may be monitored. These determinations refer to the amount of time (actual or predicted) 
that it takes for the driver to pick up the merchandise, or the vendor to prepare the 
merchandise, or when the driver is able to pick up the merchandise once it is ready for such 
pick up. This time is calculated by several factors including the specific menu item selected, 
restaurant activity, restaurant hours, outstanding orders, etc. 

Driver table 356 contains information about the driver's hired by the meal delivery 
service. Fig. 5 illustrates a sample record of driver table 356. As shown in Fig. 5, driver 
table 356 contains fields corresponding to, for example, driver identification code, driver 
name and address, starting location, current location, driver history, contractor status, clock in 
date and time, clock out date and time, and driver reconciliation. 

The driver location, in one embodiment, is determined by monitoring the driver's 
delivery route (i.e., at home office, at customer's site, at restaurant site, en route to or from 
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customer or restaurant, etc.) and estimating the driver's location coordinates using standard 
global position software in conjunction with the driver's communicated position. For 
example, the driver may communicate to the dispatcher that the driver has just picked up a 
delivery from a subscribing restaurant. The global position software can determine the 
driver's location coordinate based on such information (i.e., the coordinate associated with 
the restaurant's location). 

Most of the fields illustrated in Fig. 5 are self explanatory. As described more fully 
below, tKIffici^ U B 
andlleliYeroutstanding 

driver history data is monitored and utilized to reward drivers whose work a^hd^ic^and 
SSKj^ ^ As further 

described below, where more than one available driver is in the same relative position to 
effectuate a meal delivery, the driver with a more favorable driver history will be selected for 
order execution, resulting in greater revenue to that driver. 
Checkinandc^ 

drivers. Moreover, driver reconciliation data easily allows the driver, dispatcher "and meal 
delivery service to determine the amount of cash, tips and credit card receipts that are 
collected by the driver for each shift. 

The orders table 358 contains information about outstanding meal delivery orders 
placed by customers. Fig. 6 illustrates a sample record of orders table 358. As shown in Fig. 
6, orders table 358 contains open meal delivery order having fields corresponding to order 
number, customer identification number, order status, requested delivery date and time, 
dispatch date and time, meal pick up date and time, estimated and actual delivery date and 
time, meal price, additional charges and gratuity. 

Additional charges may relate to a request for utensils, condiments or a store run. A 
store run allows the customer to instruct a driver to make an additional stop to pick up other 
meal related items such as a bottle of wine, dessert, etc. It should be noted that the customer 
may or may not designate to include the gratuity in the initial request. 

By monitoring the times associated with the order request, pick up and delivery, a 
customer may be informed of any delays or the general status of the order. Such information 
may be communicated by telephone, e-mail, facsimile, or some other manner. Moreover, the 
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order status is a real time update providing information to the dispatcher and/or customer as 
to the progress of the delivery process. 

The data in orders table 358, as well as the customer table 352, restaurant table 354 
and driver table 356, are routinely updated. It should be understood that some information in 
certain fields are accessible by the meal delivery service only, and other information is 
accessible by the customer, driver dispatcher, operator, customer service representative 
and/or meal delivery service. For example, menu item description data is information 
provided by the restaurant to the customer via the central controller 110 operated by the meal 
delivery service. Driver reconciliation data, however, is data that would only be available to 
the driver, dispatcher and meal delivery service. Further, all data that is personal to the 
customer (i.e., identification and credit card information) and the driver/dispatcher/ delivery 
service (i.e., driver reconciliation data) is secured by utilization of encryption techniques and 
table access control mechanisms. 

The process of using data from customer table 352, restaurant table 354, driver table 
356 and orders table 358 to execute meal delivery orders placed by customers, as well as the 
other operations of the system described with reference to Figs. 1 and 2, is represented in the 
flowcharts of Figs. 7-9 and diagram 10, described in detail below. 

Central controller 110 uses customer table 352, restaurant table 354, driver table 356 
and orders table 358 to execute the registration, monitoring and fulfillment processes 
described below. 

Rg gisS^S^ivridl Of der PrbctSs 

Registration is the preliminary process in which the meal delivery service collects 
information and serves at least the following purposes: (1) acquiring address information for 
delivering meals when executing a meal delivery order; (2) transmitting messages (electronic, 
telephone, mail, etc.) to customers such as transaction confirmations, order updates, etc.; and 
(3) effectuating login by comparing identifier information entered by the customer during the 
login process to the stored personal identifier information provided at registration. The 
delivery order process enables a customer to submit one or more orders when the required 
information is received by the meal delivery service. 

^I^^^^^E^I^7, thexustdm^o^^i to the website of the meal delivery 
service(step 702) via user interface device 120. In one embodiment, access may be 
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effectuated by clicking on a hyperlink associated with the meal delivery website. The 
customer is then prompted to register or log into the system depending on whether the 
customer's current information has been updated. It should be noted that in one embodiment, 
anyone who visits the website (registered customer, first time visitor, etc.) may browse the 
cuisine types, participating restaurants and menu items offered by the meal delivery service. 
As a prerequisite to placing a meal delivery order, however, the required registration 
information must be complete. 

In step 704, central controller 110 determines whether the registration information has 
been received by customer table 352. If such information has not been completed, the 
customer is prompted to complete the registration information (step 706). If however, the 
customer registration fields have already been completed, the customer is queried as to 
whether any of the information requires updating (step 708). In one embodiment, each time 
the customer attempts to log in to the order deliver web page, central controller 1 10 generates 
a query as to whether customer information requires updating. In another embodiment, this 
query is only made periodically (i.e., biannually, or when stored credit card expiration date is 
met). If updating is required, the customer provides the new or additional customer 
information in step 710. When the customer information has been received and stored in 
customer table 352, a message is displayed on the customer's user interface device 120, 
informing the user that the registration process is complete - i.e., "Success! Your information 
has been entered into our table." 

In step 712, the customer logs in tSlheorder delivery web page.f The customer 
accesses this page by selecting a prompt for such access available on the customer's user 
interface device 120 and by entering the authorized customer identification code and personal 
identifier or password that is compared to the password previously stored in table 352. In one 
embodiment, the prompt may be accessed by clicking on a link displayed by the user 
interface device 120 GUI using a standard computer mouse. 

In step 714, the customer selecTs ^ 
deliverS^dlderififi th e des i^djim^ soon as possible, tomorrow 

8:00PM, etc.). In one embodiment, these parameters may affect the choice of meal providers 
with which a customer may place an order. For example, customers will only have access to 
participating restaurants that are located within its geographic region and where the hours of 
operation are commensurate with the desired delivery time. 
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The customer may then choose a cuisine type (step 716) such as, but not limited to the 
following - African, American, Asian, Barbecue, California Cuisine, Chinese, Desserts, 
Ethiopian, French, Indian, Italian, Japanese, Kosher, Mediterranean, Mexican/Latin, Middle 
Eastern, Seafood and Vietnamese. A list of participating restaurants that meet the cuisine 
type and geographic area parameters will then be presented on the customer user interface 
device 120 one or more of which may be selected by the customer in step 718. 

Based on the restaurant information stored in restaurant table 354, the central 
controller 1 1 0, in step 720, d ^rmin es_^ethgr t he res tauran t is able t o prepare a mearirTtlie 
tir^constra^ I f the me^j yovideils^ ^ 

|wit^ as su cliand is prompted 

^change-the-deliveiyjime jand/orrestaurant however, the meal provider can 

satisfy a meal order to meet the customer's desired delivery time, a menu listing the menu 
items of the selected restaurant appears on the customer's user interface device 120. The 
menu includes the menu item name, description and price for each menu item. Moreover, 
additional options such as special preparations (i.e., medium rare, extra spicy, etc.) may be 
displayed. The information associated with participating restaurant's menu items is stored 
in, and accessed from, the restaurant table 354 by central controller 110. 

The customer may then select the desired menu items (step 722). It should be noted 
that the customer may view a listing of the chosen menu items as each item is selected with 
the individual prices and total price included. In one embodiment, this is accomplished by 
using electronic shopping cart technology currently employed by internet retail websites. 

In step 724, the customer is queried as to whether the purchase of utensils is desired. 
If the purchase of utensils is desired, the customer is prompted, in step 726, to indicate the 
number of sets of utensils that are required. In step 728, the customer is further queried as to 
whether a store run is desired. As described above, a store run is a separate stop by the 
driver, requested by the customer, for additional goods related to the delivered meal (i.e., stop 
at a liquor store for a bottle of wine). If selected, the customer is prompted to provide 
specific instructions with respect to the store run (step 730). The customer is then queried, in 
step 732, as to whether a gratuity is to be included with the meal delivery order. If the 
customer desires to include a gratuity, the amount is entered in step 734. Ordering utensils, 
requesting a store run and including a gratuity in the meal delivery order incurs additional 
charges. The CPU 240 calculates the meal order price total, including the menu item costs, 
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the number of utensil settings, store run(s) and gratuity, in step 736, and the amount is 
communicated to the customer via user interface display 120. Finally, the method of 
payment is selected (step 738) and the order is submitted (step 740). In one embodiment, the 
customer has the opportunity to review, change and/or cancel its order(s). Once the order is 
submitted, an order number is assigned and the data associated with the order is stored in the 
orders table 358. 

It should be noted that the meal delivery service, at the orders web page, may increase 
its revenues in several manners. In one embodiment, the delivery service may charge 
participating restaurants a fee each time a customer orders a meal. Moreover, the service 
may also charge the customer a delivery fee (i.e., $5.95 per order), in addition to charging 
customers for utensils and store runs. The meal delivery service may also offer the 
participating restaurants advertising space at its website (i.e., banner, listing, etc.) or in its 
book productions distributed to customers. Furthermore, the meal delivery service may offer 
memberships to customers who use the service frequently resulting in favorable revenues to 
the service but lower delivery charges to customers who place numerous orders. Finally, the 
meal delivery service may offer its customers coupons and gift certificates - programs to 
further increase revenues. 



Fulfillment Process 

Fig. 8 is a flowchart illustrating the monitoring and fulfillment processes in 
accordance with one representative embodiment. In step 800, the central controller 110 
receives the meal delivery order and stores the data in the appropriate tables 352, 354, 356 
and 358 of data storage device 250. Data relating to the meal order (i.e., customer location, 
selected restaurant, selected menu items, desired delivery time) is communicated to operator 
160 (step 805). The information is then communicated to the central controller 110 and the 
dispatcher 150. The dispatcher determines from central controller 1 10 whether one or more 
5 rive^ for fajfillin g the outstanding-meaLdeliveiyro^er| The dispatcher is in 

c ^st^fcomm^icat^ As described more 

fully below, pocketnet 140 enables the dispatcher 150 tojdetemu^ 

ofthe driver andthe driver's status (i.e., waiting for next order, driving to restaurant for meal 
piclcup, etc.) via_cgntralxontroller-l-lQr-lf, in step 810, the dispatcher determines that no 
drivers are available for a timely execution of the outstanding order, the order is placed in a 
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o qyajejQL^ andlh iT^to^ 
(step 815). O^ly-executfe 

weather conditions, restaurant delay, and the like. In addition to taking these conditions into 
account, the CPU 240 of central controller 1 l^eteroines.estimated-deliYeiy^time-based^on? 
t he number o f availabl^riyers^ and th e available drivers^ average speecLJtojo^ 
thexustomermay- beinfom 

amount of time (i.e., fifteenminutes). In stg p 820, it is determined whether the customer is 
willing to accept a delivery time later than what was requested. The customer may either 
cancel the order (step 820) or reschedule delivery for the next available delivery (step 805). 

Upon determining, in step 810, that the at least one driver is available to execute a 
meal delivery order, the order(s) are communicated to the driver via pocketnet 140 (step 830) 
and the order is transmitted to the restaurant via restaurant user interface device 130. In one 
embodiment, the restaurant user interface device is a facsimile machine. In other 
embodiments, the user interface device may be a computer configured to receive e-mail, a 
telephone, etc. By alerting the driver and the restaurant of the outstanding order, the two 
parties, working in parallel, minimize meal deliver y time. 

in s,ep 840, d^KME^ Sjiwg (Driver selec,ion is described 
in detail below with reference to Fig. 9.) If the order is accepted (step 845), the driver 
proceeds to the restaurant (step 850). While the driver is proceeding to the restaurant, the 
restaurant, in step 855, preparesjhe meal, ideally within the driver-predict arrival time^ An one 
embodiment, the driver predict arrival time is the time that the CPU 240 determines that the 
driver will at arrive at a subscribing restaurant based in various parameters including, but not 
limited to, desired delivery time, weather conditions, traffic condition, available drivers, 
average driver speed, driver location, customer location and other outstanding orders. The 
CPU 240 of central controller 110 further determines which available driver will result in 
meeting customers' desired order time while maximizing the number of deliveries that may 
be effectuated in a given time period. The results of the calculations performed by CPU 240 
assists the dispatcher 150 in selecting the appropriate driver to accomplish the goals afforded 
above. 

In step 860, the driver receives the prepared meal and the dispatcher is alerted in step 
865. It should be noted that the pocketnet 140 enables the dispatcher (and thus the customer) 
to be frequently informed of the meal delivery status. Of particular significance is the driver 
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dispatch time, meal pick up time and meal delivery time (estimated and actual). This data is 
communicated from the driver to the dispatcher via pocketnet 1 40 and then communicated to 
the customer via customer user interface device 120. 



In step 870, th^spatcher.determines via central controll_er_l,l,0_whether_another order 



is pending at j hejamejgstaurant and/or^jigtihgr addi tional meal pick-u p(s) at othe r 
restaura nt(s) are appropriate ^Ior to meal deH yeryJfOnce again, CPU 240 balances driver 
waiting time, with outstanding desired delivery times as well as available driver data to 



dg^mine whether the driver should deliver the picked up meaf(s) immediately oTfurtHer 



Si 



pick up additi onal meal(s). I f a nother meal is to b e picked up,, the restaurant prepar e s -the* 



subseq^^ Jf, however, ho 

additional meals are to be picked up, the driver delivers the meal directly to the customer 
(along with store runs that have been requested), in step 875, and then alerts the dispatcher 
that the meal has been delivered. 

In step 880, it is determined whether the driver is carrying additional meals for 
delivery. If the driver has yet to deliver all of the meals picked up from the restaurants, the 
meals are delivered (step 875). Upon delivery of the picked up meals, the driver waits for 
another order to be transmitted by dispatcher 150 (step 885). 

By constantly monitoring, in real time, the location of the customers', restaurants' and 
available drivers' with respect to outstanding orders, along with other data, such as weather 
conditions, traffic conditions, restaurant activity, meal preparation time, number of 
outstanding orders, store runs, average driver speed, and the like, the delivery service has the 
ability to optimize its operations. Delivery service optimization, in one embodiment, may 
mean meeting the outstanding customer desired delivery times most reliably. In other 
embodiments, delivery service optimization may be maximizing the number of deliveries, 
reducing the number of drivers,\griori^ times withinj 

pr edetermined amount of ^time-yet-dlowing-larger-orders^i.e^iughgi ^ost orde rs ) within t^ 
ti me fra meto_be executediirst.^The delivery service is also optimized by selecting drivers 
based on location, driver history and contractor status. The delivery service is further 
optimized by increasing operational efficiencies, such asj^aljdmejocation tracking-abilities, 



real timeon.dutyjjracking v automatic reconciliation ( meal cha rges, credit card receipts, j 
(gratuitfes, etcJ_and.reaLtime order jtatu s monitoring. ~^ 
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Dci^er Sele<^ 

Fig. 9 is a flowchart illustrating the driver selection process in accordance with one 
representative embodiment. During the order fulfillment process (step 830), the dispatcher, 
with the assistance of central controller 110, determines the most appropriate driver to assign 
an outstanding order. Such assignment is often based on the service optimization goals stated 
above (i.e., minimizing delivery time, meeting desired delivery time, considering driver 
location with respect to restaurant and customer location, etc.). In one embodiment, central 
controller 1 10 is programmed to consider other parameters in addition to the goals described 
above. These additional considerations further maximize the efficiency of delivering 
prepared meals to customers. 

Referring to Fig, 9, once the dispatcher determines that a driver is required (step 905), 
a further determination is made as to the number of drivers that are available. An available 
driver is a driver who has clocked in (on duty) via, for example, pocketnet 140, and is 
available to pick up a meal order. 

In step 910, the central controller 110 determines whether multiple drivers are 
available. If central controller 1 10, in step 915, determines that no drivers are available, the 
customer is alerted, in step 920, that the service is subject to temporary delay. Furthermore, 
if only one driver is clocked in and central controller 110 determines that the driver is 
unavailable (step 925), the customer is likewise alerted that the service is subject to 
temporary delay (step 920). If, however, there is only one driver clocked in and that driver is 
available, the central controller informs the dispatcher to select that driver to execute the 
outstanding meal order (step 955). 

Returning to step 910, if the central controller determines that multiple available 
drivers are on duty, a determination is made in step 930 as to which driver is in the best 
location to effectuate the quickest delivery and to meet the outstanding desired delivery time. 
This is accomplished by calculations performed by CPU 240 with respect to traffic 
conditions, driver's average speed, geographic position, and the like. If one available driver 
meets this goal, that driver is selected in step 935 based on the proximity/history/contractor 
status algorithm executed by CPU 240. 

However, if the location of two or more available drivers results in an insignificant 
advantage with respect to maximizing the predetermined delivery goals, central controller 
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1 1 0 determines whether one of the available drivers has a higher service history variable. 
The favorable service history variable is a number associated to each driver based on a 
driver's promptness in meeting scheduled pick ups and deliveries, willingness to accept 
orders, work attendance, safety record, etc. In one embodiment, a number, for example 1 
through 5 is assigned at the end of the customers work shift (or missed shift if unexcused 
absence). If among a multiple of available drivers that have a similar geographic position, 
one has a higher service history variable (step 940), that driver is selected in steps 935 and 
955 based on the proximity/history/ contractor status algorithm executed by CPU 240. 

If, however, two or more drivers having the same relative geographic positions and 
same service history variable are available for a meal delivery order, central controller 1 10 
determines whether one of the available drivers has a more favorable contractor status. If 
among a multiple of available drivers that have a similar geographic position (step 935) and 
service history variable (step 940), one has a more favorable contractor status (step 945), that 
driver is selected in steps 935 and 955 based on the proximity/history/ contractor status 
algorithm executed by CPU 240. 

If, however, two or more drivers having the same relative geographic positions, same 
service history variable and same contractor status are available for a meal delivery order, 
central controller 110 determines whether one of the available drivers has longer down time 
for the current working shift. Down time is the amount of time that the CPU 240 has 
determined that the driver has spent waiting in between assigned order execution. Selecting a 
driver based on down time ensures that drivers share more equally the number of deliveries 
outstanding during a given work shift. If among a multiple of available drivers that have a 
similar geographic position (step 935), service history variable (step 940), and contractor 
status (step 945), one has a longer down time (step 947), that driver is selected in steps 935 
and 955 based on the proximity/history/contractor status algorithm executed by CPU 240. 

Finally, if two or more drivers are determined to have the same relative geographic 
position, service history, contractor status and down time, a driver is selected via a random 
number generator executed by central controller 1 10 (step 950 and 955). Applying a driver 
selection process based on favorable locations, service history, contractor status and down 
time further maximizes the efficiency of the meal delivery system and method described 
herein as drivers are selected based on parameters that decrease meal delivery times and meet 
customers' desired delivery times. 
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As described above, communication between the drivers' pocketnets 140 and the 
central controller 1 10 and the dispatcher is preferably by a wireless communication and/or 
paging means employing known communication protocols capable of encrypting and 
decrypting information communicated between these units. The pocketnets 140 enable the 
drivers, central controller 1 10 and dispatchers 150 to have real time access to the data 
required to access an outstanding meal delivery order. Such technology further increase the 
efficiency of the method and system described herein. Further described below are some of 
the functions available, in one embodiment, using the pocketnets 140 shown in Fig. 1. 

The View Order function allows the driver to review the meal order that is being 
picked up at the participating restaurant. Such information is useful in ensuring that the 
correct menu items are picked up from the selected restaurant. Moreover, the driver is alerted 
as to requested store runs and can determine the most efficient itinerary immediately. The 
Re-send Order function enables the order to be transmitted again if required. 

The Leave Restaurant function informs the central controller 1 1 0 and dispatcher 1 50 
that a meal order has been picked up. Accordingly, this important status and scheduling 
information may be known immediately. 

The Clear function allows the driver to delete data that is no longer required (i.e., 
certain data concerning executed orders). 

The Call Customer function enables the driver to select an order number and forward 
a message to customer expecting a delivery with respect to that order. For example, the 
driver can inform the customer (or inform the customer service representative 170 or central 
controller 1 10 for communication to the customer) that the driver is in the lobby or on the 
floor of the customer's apartment or office building, or that the driver is in traffic, or that the 
driver cannot find the customer's location. 

The Display Position function provides the central controller 110 and dispatcher 150 
with information regarding the driver's location. Whereas the Driver Location function 
informs the customer of the driver's location. 

The Clock In function informs the central controller 1 10 and dispatcher 150 when the 
driver has begun a shift, and the Shift Complete function identifies when the driver's shift has 
ended. This function also effectuates the driver reconciliation operations described above 
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(i.e., cash collected, credit receipts collected, gratuities collected). The Request Break and 
Back To Work functions further identifies the driver's work hours. 

The Request Back To Base informs the driver to report to the dispatcher and is 
usually effectuated at the end of a shift. Finally, the change payment type authorizes the 
driver to accept a different type of payment than specified when the customer placed the meal 
order. 

As noted above, although the described embodiment relates to delivery of prepared 
meals, the delivered goods may apply to any type of merchandise (i.e., flowers, commodities, 
clothing, books, hardware, etc.). Moreover, it should be noted that methods and systems 
described herein relate to the effectuation of rapid delivery services, longer duration delivery 
services, delayed delivery services, delivery of perishable and non-perishable goods, delivery 
in local and broad geographic areas, retail deliveries, wholesale deliveries, commercial 
distribution, non-commercial distribution, etc. 

It will further be apparent to those skilled in the art that various modifications and 
variations can be made in the system and processes of the present invention without departing 
from the spirit or scope of the invention. Thus, it is intended that the present invention covers 
the modifications and variations of this invention provided they come within the scope of the 
appended claims and their equivalents. In this context, equivalents means each and every 
implementation for carrying out the functions recited in the claims, even if not explicitly 
described herein. 
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CLAIMS 

What is claimed is: 

1 . A method of delivering merchandise, comprising: 
receiving at least one order for said merchandise; 
monitoring driver availability for said merchandise delivery; and 

selecting driver based on driver availability and delivery service optimization. 

2. The method according to claim 1, further comprising: 
communicating the merchandise delivery order to a participating vendor. 

3. The method according to claim 2, further comprising: 
calculating a driver predict merchandise pick up time. 

4. The method according to claim 3, wherein the merchandise is prepared for 
pick up by the participating vendor within the driver predict merchandise pick up time. 

5. The method according to claim 1, wherein the delivery service optimization is 
met when the number of deliveries executed is maximized. 

6. The method according to claim 1, wherein the delivery service optimization is 
met when customer desired delivery time is met within a predetermined time of said desired 
delivery time. 

7. The method according to claim 1, wherein the delivery service optimization is 
met by maximizing revenues. 

8. The method according to claim 1, wherein the delivery service optimization is 
met by maximizing net profits. 

9. The method according to claim 7, wherein the delivery service optimization is 
met by reducing the number of drivers that are available to execute outstanding orders. 
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1 0. The method according to claim 7, wherein revenues are maximized by 
assessing a delivery fee from a customer for each placed order. 

1 1 . The method according to claim 7, wherein revenues are maximized by 
assessing a commission from a participating vendor when an order is placed with the vendor. 

12. The method according to claim 7, wherein revenues are maximized by 
assessing a fee from a participating vendor for listing the vendor at a delivery service website, 

13. The method according to claim 12, wherein the delivery service assess an 
additional fee from the vendor for posting a vendor advertisement. 

14. The method according to claim 13, wherein the vendor advertisement is a 
banner advertisement. 

15. The method according to claim 1, further comprising: 
monitoring traffic conditions; 

determining the effect of traffic conditions on driver pick up time; and 
utilizing traffic condition data to select the driver based on delivery service 
optimization. 

1 6. The method according to claim 1 , further comprising: 
monitoring driver average speed; 

determining the effect of driver average speed on driver pick up time; and 
utilizing driver average speed data to select the driver based on delivery service 
optimization. 

1 7. The method according to claim 1, further comprising: 
monitoring vendor conditions to determine food preparation time; 
determining the effect of vendor conditions on driver pick up time; and 
utilizing vendor condition data to select the driver based on delivery service 

optimization. 



2/28/2006, EAST Version: 2.0.3.0 



WO 01/52163 PCT/US01/00399 

22 

1 8. The method according to claim 1, further comprising: 
monitoring store run requests; 

determining the effect of store run requests on driver delivery time; and 
utilizing store run request data to select the driver based on delivery service 
optimization. 

1 9. The method according to claim 1 5, further comprising: 
monitoring driver average speed; 

determining the effect of driver average speed on driver pick up time; and 
utilizing driver average speed data to select the driver based on delivery service 
optimization. 

20. The method according to claim 19, further comprising: 
monitoring vendor conditions to determine merchandise ready time; 
determining the effect of vendor conditions on driver pick up time; and 
utilizing vendor condition data to select the driver based on delivery service 

optimization. 

21 . The method according to claim 20, further comprising: 
monitoring store run requests; 

determining the effect of store run requests on driver delivery time; and 
utilizing store run request data to select the driver based on delivery service 
optimization. 

22. The method according to claim 1, further comprising: 
tracking driver location in approximately real time; 

comparing driver location to customer location and vendor location; and 
utilizing location data to select the driver based on delivery service optimization. 

23. The method according to claim 22, wherein the driver location, customer 
location and vendor location are determined using global position software. 
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24. The method according to claim 1 , further comprising automatically 
reconciling money, credits and gratuities collected by the driver. 

25. The method according to claim 1 , further comprising automatically 
communicating status of merchandise delivery order to customer. 

26. The method according to claim 1 , wherein the status is communicated through 
the internet. 

27. A method of selecting a driver for delivering merchandise, comprising: 
determining whether multiple drivers are available; and 

selecting said driver based upon at least one criterion consistent with delivery service 
optimization. 

28. The method according to claim 27, wherein the criterion for selecting said 
driver is based upon proximity of driver to customer and participating vendor. 

29. The method according to claim 28, wherein the proximity is determined based 
on driver's relative distance to customer and vendor. 

30. The method according to claim 29, wherein the proximity is determined based 
on a calculated time for the driver to reach the vendor and the customer. 

3 1 . The method according to claim 27, wherein the criterion for selecting said 
driver is based upon favorable driver history. 

32. The method according to claim 27, wherein the criterion for selecting said 
driver is based upon favorable contractor status. 

33. The method according to claim 27, wherein the criterion for selecting said 
driver is based upon reducing individual driver down time. 
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34. A system for delivering merchandise, comprising: 
means for receiving at least one order for merchandise; 

means for monitoring driver availability for said merchandise; and 
means for selecting driver based on driver availability and delivery service 
optimization. 

35. The system according to claim 34, further comprising: 

means for communicating the merchandise delivery order to a participating vendor. 

36. The system according to claim 35, further comprising: 
means for calculating a driver predict merchandise pick up time. 

37. The system according to claim 36, wherein the merchandise is prepared by the 
participating restaurant within the driver predict merchandise pick up time. 

38. The system according to claim 34, wherein the delivery service optimization is 
met when the number of deliveries executed is maximized. 

39. The system according to claim 34, wherein the delivery service optimization is 
met when customer desired delivery time is met within a predetermined time of said desired 
delivery time. 

40. The system according to claim 34, wherein the delivery service optimization is 
met by maximizing revenues. 

41 . The system according to claim 34, wherein the delivery service optimization is 
met by maximizing net profits. 

42. The system according to claim 40, wherein the delivery service optimization is 
met by reducing the number of drivers that are available to execute outstanding orders. 
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43. The system according to claim 40, wherein revenues are maximized by 
assessing a delivery fee from a customer for each placed order. 

44. The system according to claim 40, wherein revenues are maximized by 
assessing a commission from a participating vendor when an order is placed with the vendor. 

45. The system according to claim 40, wherein revenues are maximized by 
assessing a fee a participating vendor for listing the vendor at a delivery service website. 

46. The system according to claim 45, wherein the delivery service assess an 
additional fee from the vendor for posting a vendor advertisement. 

47. The system according to claim 46, wherein the vendor advertisement is a 
banner advertisement. 

48. The system according to claim 34, further comprising: 
means for monitoring traffic conditions; 

means for determining the effect of traffic conditions on driver pick up time; and 
means for utilizing traffic condition data to select the driver based on delivery service 
optimization. 

49. The system according to claim 34, further comprising: 
means monitoring driver average speed; 

means for determining the effect of driver average speed on driver pick up time; and 
means for utilizing driver average speed data to select the driver based on delivery 
service optimization. 

50. The system according to claim 34, further comprising: 

means for monitoring vendor conditions to determine merchandise ready pick up 

time; 

means for determining the effect of vendor conditions on said pick up time; and 
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means for utilizing vendor condition data to select the driver based on delivery service 
optimization. 

5 1 . The system according to claim 34, further comprising: 
means for monitoring store run requests; 

means for determining the effect of store run requests on driver delivery time; and 
means for utilizing store run request data to select the driver based on delivery service 
optimization. 

52. The system according to claim 48, further comprising: 
means for monitoring driver average speed; 

means for determining the effect of driver average speed on driver pick up time; and 
means for utilizing driver average speed data to select the driver based on delivery 
service optimization. 

53. The system according to claim 52, further comprising: 

means for monitoring vendor conditions to determine merchandise ready pick up 

time; 

means for determining the effect of vendor conditions on said pick up time; and 
means for utilizing vendor condition data to select the driver based on delivery service 
optimization. 

54. The system according to claim 53, further comprising: 
means for monitoring store run requests; 

means for determining the effect of store run requests on driver delivery time; and 
means for utilizing store run request data to select the driver based on delivery service 
optimization. 

55. The system according to claim 34, further comprising: 
means for tracking driver location in approximately real time; 

means for comparing driver location to customer location and vendor location; and 
means for utilizing location data to select the driver based on delivery service 
optimization. 
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56. The system according to claim 55, wherein the driver location, customer 
location and vendor location are determined using global position software. 

57. The system according to claim 34, further comprising means for automatically 
reconciling money, credits and gratuities collected by the driver. 

58. The system according to claim 34, further comprising means for automatically 
communicating status of merchandise delivery order to customer. 

59. The system according to claim 34, wherein the status is communicated 
through the internet. 

60. A system for selecting a driver for delivering merchandise, comprising: 
means for determining whether multiple drivers are available; and 

means for selecting said driver based upon at least one criterion consistent with 
delivery service optimization. 

61 . The system according to claim 60, wherein the criterion for said selecting 
means of said driver is based upon proximity of driver to customer and participating vendor. 

62. The system according to claim 61 , wherein the proximity is determined based 
on driver's relative distance to customer and vendor. 

63. The system according to claim 62, wherein the proximity is determined based 
on a calculated time for the driver to reach the vendor and the customer. 

64. The system according to claim 60, wherein the criterion for said selecting 
means of said driver is based upon favorable driver history. 

65. The system according to claim 60, wherein the criterion for said selecting 
means of said driver is based upon favorable contractor status. 
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66. The system according to claim 60, wherein the criterion for said selecting 
means for said driver is based upon reducing individual driver down time. 

67. Computer executable software code stored on a computer readable medium, 
the code for delivering merchandise, comprising: 

code to receive at least one order for meal delivery; 

code to monitor driver availability for said merchandise delivery; and 

code to select driver based on driver availability and delivery service optimization. 

68. Computer executable software stored on a computer readable medium, the 
code for selecting a driver for delivering merchandise, comprising: 

code to determine whether multiple drivers are available for delivery; and 
code for selecting said driver based upon at least one criterion consistent with delivery 
service optimization. 

69. A computer readable medium having computer executable software stored 
thereon, the code for delivering merchandise, comprising: 

code to receive at least one order for merchandise delivery; 

code to monitor driver availability for said merchandise delivery; and 

code to select driver based on driver availability and delivery service optimization. 

70. A computer readable medium having computer executable software stored 
thereon, the code for selecting a driver or delivering merchandise, comprising: 

code to determine whether multiple drivers are available for delivery; and 
code for selecting said driver based upon at least one criterion consistent with delivery 
service optimization. 

71. A programmed computer for delivering meals, comprising : 

a memory having at least one region for storing computer executable program code; 

and 

a processor for executing the program code store in memory, wherein the program 
code includes: 



2/28/2006; EAST Version: 2.0.3.0 



WO 01/52163 PCT/US01/00399 

29 

code to receive at least one order for merchandise delivery; 

code to monitor driver availability for said merchandise delivery; and 

code to select driver based on driver availability and delivery service optimization. 

72. A programmed computer for delivering merchandise, comprising: 

a memory having at least one region for storing computer executable program code; 

and 

a processor for executing the program code store in memory, wherein the program 
code includes: 

code to determine whether multiple drivers are available for delivery; and 
code for selecting said driver based upon at least one criterion consistent with delivery 
service optimization. 

73. A system for delivering merchandise, comprising: 

a database for storing customer information, order information, vendor information 
and driver information relating to delivery of merchandise to said customer; and 

a central processing unit configured to monitor driver availability for said 
merchandise delivery, and select driver based on driver availability and delivery service 
optimization. 

74. The system according to claim 73, further comprising: 

a user interface device configured to communicate the merchandise delivery order to a 
participating vendor. 

75. The system according to claim 74, wherein the central processing unit is 
configured to calculate a driver predict merchandise preparation pick up time. 

76. The system according to claim 75, wherein the merchandise is prepared by the 
participating vendor within the driver predict merchandise pick up time. 

77. The system according to claim 73, wherein the delivery service optimization is 
met when the number of deliveries executed is maximized. 
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78. The system according to claim 73, wherein the delivery service optimization is 
met when customer desired delivery time is met within a predetermined time of said desired 
delivery time. 

79. The system according to claim 73, wherein the delivery service optimization is 
met by maximizing revenues. 

80. The system according to claim 73, wherein the delivery service optimization is 
met by maximizing net profits. 

8 1 . The system according to claim 79, wherein the delivery service optimization is 
met by reducing the number of drivers that are available to execute outstanding orders. 

82. The system according to claim 79, wherein revenues are maximized by 
assessing a delivery fee from a customer for each placed order. 

83. The system according to claim 79, wherein revenues are maximized by 
assessing a commission from a participating vendor when an order is placed with the vendor. 

84. The system according to claim 79, wherein revenues are maximized by 
assessing a fee a participating vendor for listing the vendor at a delivery service website. 

85. The system according to claim 84, wherein the central processing unit 
calculates an assessed delivery service fee from the vendor for posting a vendor 
advertisement. 

86. The system according to claim 85, wherein the vendor advertisement is a 
banner advertisement. 

87. The system according to claim 73, wherein the central processing unit is 
further configured to monitor traffic conditions, determine the effect of traffic conditions on 
driver pick up time; and utilize traffic condition data to select the driver based on delivery 
service optimization. 
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88. The system according to claim 73, wherein the central processing unit is 
further configured to monitor driver average speed, determine the effect of driver average 
speed on driver pick up time, and utilize driver average speed data to select the driver based 
on delivery service optimization. 

89. The system according to claim 73, wherein the central processing unit is 
further configured to monitor vendor conditions to determine merchandise ready time, 
determine the effect of vendor conditions on driver pick up time, and utilize vendor condition 
data to select the driver based on delivery service optimization. 

90. The system according to claim 73, wherein the central processing unit is 
further configured to monitor store run requests, determine the effect of store run requests on 
driver delivery time, and utilize store run request data to select the driver based on delivery 
service optimization. 

91 . The system according to claim 77, wherein the central processing unit is 
further configured to monitor driver average speed, determine the effect of driver average 
speed on driver pick up time, and utilize driver average speed data to select the driver based 
on delivery service optimization. 

92. The system according to claim 91, wherein the central processing unit further 
is configured to monitor vendor conditions to determine merchandise preparation time, 
determine the effect of vendor conditions on driver pick up time, and utilizes vendor 
condition data to select the driver based on delivery service optimization. 

93. The system according to claim 92, wherein the central processing unit is 
further configured to monitor store run requests, determine the effect of store run requests on 
driver delivery time, and utilize store run request data to select the driver based on delivery 
service optimization. 
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94. The system according to claim 73, wherein the central processing unit is 
further configured to track driver location in approximately real time, compare driver location 
to customer location and vendor location, and utilize location data to select the driver based 
on delivery service optimization. 

95. The system according to claim 94, wherein the a central controller uses global 
position software to determine driver location, customer location and vendor location. 

96. The system according to claim 73, wherein the central processing unit is 
further configured to automatically reconcile money, credits and gratuities collected by the 
driver. 

97. The system according to claim 73, further comprising a user interface device 
configured to automatically communicate status of merchandise delivery order to customer. 

98. The system according to claim 73, wherein the status is communicated 
through the internet. 

99. A system for selecting a driver for delivering merchandise, comprising: 

a database for storing customer information, order information, vendor information 
and driver information relating to delivery of merchandise to said customer; and 

a central processing unit configured to determine whether multiple drivers are 
available, and select said driver based upon at least one criterion consistent with delivery 
service optimization. 

1 00. The system according to claim 99, wherein the criterion for said selecting 
means of said driver is based upon proximity of driver to customer and participating vendor. 

101. The system according to claim 100, wherein the proximity is determined based 
on driver's relative distance to customer and restaurant. 
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1 02. The system according to claim 101, wherein the proximity is determined based 
on a calculated time for the driver to reach the restaurant and the customer. 

103. The system according to claim 99, wherein the criterion for said selecting 
means of said driver is based upon favorable driver history. 

104. The system according to claim 99, wherein the criterion for said selecting 
means of said driver is based upon favorable contractor status. 

105. The system according to claim 99, wherein the criterion for said selecting 
means for said driver is based upon reducing individual driver down time. 

106. The method according to claim 1, wherein the merchandise is at least one 
prepared meal. 

1 07. The method according to claim 27, wherein the merchandise is at least one 
prepared meal. 

108. The system according to claim 34, wherein the merchandise is at least one 
prepared meal. 

109. The method according to claim 60, wherein the merchandise is at least one 
prepared meal. 

1 1 0. The computer executable software code according to claim 67, wherein the 
merchandise is at least one prepared meal. 

111. The computer executable software code according to claim 68, wherein the 
merchandise is at least one prepared meal. 

1 12. The computer readable medium according to claim 69, wherein the 
merchandise is at least one prepared meal. 
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113. The computer readable medium according to claim 70, wherein the 
merchandise is at least one prepared meal. 

1 14. The computer readable medium according to claim 71 wherein the 
merchandise is at least one prepared meal. 

115. The computer readable medium according to claim 72, wherein the 
merchandise is at least one prepared meal. 

1 16. The computer readable medium according to claim 73, wherein the 
merchandise is at least one prepared meal. 

117. The system according to claim 73, wherein the merchandise is at least one 
prepared meal, and the vendor is at least one participating restaurant. 

118. The system according to claim 99, wherein the merchandise is at least one 
prepared meal. 
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